The present invention relates to mobile device computing, and more specifically to portable applications bundled with native program extensions for enhanced functionality.
Unlike desktop computers, mobile devices such as cell phones are not built on a common platform. Most desktop machines are based on the Intel x86 architecture, sharing a common instruction set, bus model, and standard components such as mouse, keyboard, hard drive, display, etc. Operating systems are fairly standardized as well, with the majority of desktop machines running some version of Microsoft Windows. By contrast, mobile devices are built around a wide variety of different hardware and operating systems. Processors from Texas Instruments, Qualcomm, Siemens/BenQ, Broadcom, Marvell, and others are commonly used. Proprietary platforms and nonstandardized components such as Global Positioning System (GPS) receivers and cameras further complicate the picture. Many mobile device vendors develop their own operating systems or license operating systems from multiple providers. This creates a fragmented market of mobile devices lacking common hardware and software for application developers to target.
To address this problem, several common software platforms have been developed. Each platform provides a standard application programming interface (API) for accessing functionality of an underlying device. Applications run on top of the platform. When an application wants to use a device feature, it calls the platform API. The platform translates the API call into native instructions for the particular device being used. Applications written to the platform can run on a variety of devices without dealing with hardware and operating system differences between devices. Examples of such platforms include Sun Microsystem's Java Platform Micro Edition (Java ME or J2ME), Google's Android, and Qualcomm's Binary Runtime Environment for Wireless (BREW).
Platforms often do not expose every feature of the underlying device. Some device-specific features are covered up by the abstraction of a common API. Others may be omitted from the platform to provide a “lowest common denominator” of features which exist in every device. Still others may not be widely used enough or exist at all when the platform is finalized. Additionally, code translating an API call into a native feature must be written for each device. If this translation code has not been written for a particular device, or if the device vendor did not load the translation code onto the device, then a feature may be unavailable even though both the platform and the underlying device support it.
For example, Mobile Information Device Profile (MIDP) is a set of Java ME interfaces. The first version of MIDP did not provide an API for full-screen graphics control, inhibiting the development of games on the Java ME platform. MIDP 2.0 corrected this, along with adding support for audio and multimedia playback, communications over HTTPS and other network protocols, and allowing MIDP applications to register with the operating system as handlers for certain types of network traffic. These features were available on devices before MIDP 2.0, but MIDP 1.0 did not provide a way to access them.
When a software platform does not provide features supported by the underlying device, an application programmer's options depend on the platform. Some platforms compile applications into native code for each device, providing only a cross-platform compatibility library for accessing device functions. In this case, the developer may be able to access unsupported features by calling the device operating system directly. The downside of this approach is code that is not portable to other devices. However, platforms such as Java ME do not even allow this option.
Java ME applications run inside a Java virtual machine. The virtual machine runs applications in Java bytecode, not native compiled code. The device processor won't run bytecode, and the virtual machine won't run native code. This technique, called sandboxing, prevents Java applications from accessing the device hardware or operating system directly. Sandboxed applications can only access what the virtual machine allows them to access. For instance, web browsers run Java virtual machines that forbid accessing the local file system.
A Java ME application has more limited options for accessing features outside the common platform. Java ME defines a number of optional libraries for features like Bluetooth and instant messaging. These libraries are not available on every device. A device manufacturer wishing to support such optional features can include the corresponding Java ME libraries on their devices. However, many manufacturers choose not to include such libraries, even though their devices support the underlying features.
Vendors can also create their own Java APIs for accessing device features. For instance, Research in Motion includes proprietary Java libraries for accessing additional features of their Blackberry devices. Such proprietary libraries are less desirable because they are limited to a single vendor, hampering portability of Java ME applications. In either case, these options are beyond the control of the application developer. Vendors decide whether to provide such features.
Java Native Interface (JNI) provides a third option for accessing features and services outside a java virtual machine in certain circumstances. With JNI, Java programs may directly execute native code. The Java virtual machine loads the native code into the running virtual machine process's address space and transfers control to it. When done, the native code must return control to the Java virtual machine. This differs from running Java bytecode, which runs on the Java virtual machine itself. JNI defeats any sandbox protection since native code is not bound by the restrictions imposed by the virtual machine on Java bytecode. Native code can perform any operation that any other program can perform. Because of this, high-security Java virtual machines such as the ones in web browsers do not allow JNI.
Many mobile devices do not provide JNI. Java ME defines two device configurations, Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC). CDC runs on high-end mobile devices such as some smart phones with ample computing power and memory. CLDC runs on basic mobile devices, including the majority of cell phones. Because CLDC devices lack the needed power and memory, JNI is generally not available on them. Manufacturers may optionally add JNI to a CLDC device, but few do. As before, the decision to support JNI is not under the developer's control. Application developers targeting a wide variety of cell phones can not rely on JNI for interfacing with native code.